从 0 到 1 构建直播业务系统解决方案
定位： 直播电商业务系统的整体建设方案，覆盖直播间管理、推拉流、实时互动、直播商品、交易联动、营销玩法、多租户多渠道与数据统计。 依据： 基于本仓库直播域代码与配套技术方案文档调研归纳，表达为可迁移的通用方案，不绑定具体工程实现。 读者： 新团队负责人、后端/前端/测试工程师、DBA 与运维。
1. 系统架构（技术架构视角）
系统按"客户端 → 接入 → 聚合 → 领域 → 中间件 → 数据 → 外部云"分层构建，另有横切体系贯穿全层。同步调用以 RPC 为主，云服务回调、消息广播与定时任务构成异步链路。
1.1 技术架构总图
1.2 分层职责与技术约束
| 层 | 职责 | 技术选型要点 | 关键约束 |
|---|---|---|---|
| 客户端层 | 交互与播放、渠道上下文注入 | 播放器 SDK 多端适配；全局请求拦截器统一注入渠道头 | 不自行拼渠道、不按下标重编商品序号、渠道切换清空在途请求 |
| 接入层 | 流量入口治理 | API 网关统一路由 / 鉴权 / 限流；CDN 承接静态流量 | 渠道请求头全链路透传，网关不做业务判断 |
| BFF 聚合层 | 接口编排、渠道解析、缓存 | 多级缓存 + 注解缓存；请求线程构建不可变上下文后异步并发 | 不承载业务规则；工作线程禁读 ThreadLocal；降级不跨渠道回退 |
| 领域服务层 | 业务规则与状态沉淀 | 数据库行锁串行化、状态机、唯一索引兜底 | 锁内不做远程调用；接口向后兼容，废弃需过渡期 |
| 中间件层 | 通信、缓存、异步、调度、配置 | 声明式 RPC；任务平台支持 dry-run / 游标分批 / 可重入 | 开关矩阵有明确文档；禁止越阶切换 |
| 数据层 | 业务数据与搜索索引 | MySQL 主从读写分离；ES 承接多维搜索与聚合 | 唯一约束为防重最终防线；列表查询分页前过滤 |
| 外部云服务 | 音视频与实时通信能力 | 云直播 / 云 IM / 云点播，回调驱动状态 | 回调处理幂等；回调丢失有状态兜底任务 |
| 横切体系 | 安全与可观测 | 统一认证授权、指标监控、全链路 Trace、审计日志 | 关键日志必含直播间 ID、商品 ID、渠道、TraceID |
1.3 核心链路时序
链路一：C 端商品列表（同步聚合链路）
链路二：运营弹品（写 + 异步广播链路）
1.4 业务模块关系图
链路说明：
| 链路 | 方式 | 说明 |
|---|---|---|
| C 端浏览 | 同步 | C 端 → C 端聚合服务 → 直播核心域 / 商品中心 / 会员域 |
| 运营配置 | 同步 | 管理后台 → 管理端聚合服务 → 直播核心域 |
| 开播 / 断流 | 异步回调 | 云直播回调直播间，驱动状态机 |
| 商品讲解推送 | 异步广播 | 运营操作 → 核心域写入 → IM 群属性与自定义消息广播 |
| 发券 / 提醒 / 统计 | 定时任务 | 任务调度平台扫描待处理记录，异步执行 |
2. 模块拆解
2.1 直播间管理
解决问题： 直播间全生命周期管理，是整个系统的领域根。
- 职责边界： 直播间创建、编辑、删除、开播 / 关播、主备流、录制、回放绑定；不含商品与互动内容本身。
- 核心数据模型：
- 直播间主表：主题、封面、开播 / 关播时间、平台（租户）、直播间类型、IM 群 ID、推流名称、状态、扩展信息（JSON，存放平台差异化配置）、是否广场展示。
- 直播录制记录表：直播间 ID、流名称、录制任务 ID、录制视频列表（JSON）。
- 关键接口：
- 管理端：创建 / 更新 / 删除、详情、分页、开播 / 关播、主备流切换、回放视频绑定。
- C 端：直播间详情、分页（进行中 / 回放）、是否开播、UV 上报。
- 核心流程： 创建直播间 → 调云直播生成推流地址 → 创建 IM 群组 → 在消息推送平台注册开播提醒场景 → 开播（云回调驱动状态）→ 直播中 → 关播 → 录制转码完成回调 → 绑定回放。
- 上下游依赖： 云直播、云 IM、消息推送平台、管理端聚合服务。
- 技术要点：
- 直播间类型与租户平台联动校验（某些类型仅允许特定租户），避免运营错配。
- 同一直播间的写操作（加品、排序）以数据库行锁串行化，防止并发操作互相覆盖。
- 扩展字段用 JSON 承载租户差异，避免频繁加列。
- 测试直播间由定时任务周期清理，防止脏数据流入生产列表。
2.2 推拉流与播放
解决问题： 直播音视频的采集、分发与观看体验。
- 职责边界： 推流地址生成与续期、流状态管理、播放器集成；不含业务状态机（归属直播间管理）。
- 关键能力：
- 推流地址带过期时间，支持主流 / 备流双地址，主备切换保障不中断。
- 云直播侧配置录制模板与截流审核，录制完成后回调绑定点播文件。
- 播放端：App / H5 / 小程序集成播放器 SDK；管理后台内置 Web 播放器用于运营实时预览与验收。
- 技术要点： 流名称与直播间一一对应；断流事件需驱动"已关播"兜底，避免回调丢失导致状态悬挂。
2.3 实时互动
解决问题： 直播间的实时氛围与运营触达能力。
- 职责边界： IM 群组维护、弹幕、公告、商品讲解推送、消息回调处理；不含消息内容审核策略（可在回调中扩展）。
- 核心模型： 直播间与 IM 群一一对应；讲解商品以群属性持久化（新进观众立即可见），变更以自定义消息实时广播。
- 关键接口： 群创建 / 解散、群消息发送、群属性设置、消息回调接收。
- 核心流程（商品讲解推送）：
- 运营在后台发起弹品，核心域更新关系表推送位（全局唯一：新弹品自动清除旧弹品）。
- 组装讲解商品消息体（商品、序号、价格、渠道）写入群属性，并广播自定义消息。
- C 端收到消息后按规则处理：空消息 → 清空讲解商品；渠道匹配 → 展示；渠道不匹配 → 清空旧讲解商品。
- 技术要点：
- 商品列表刷新类消息建议做客户端防抖，防抖 Key 需包含直播间与渠道。
- 旧版本消息无渠道字段时需定义兼容期行为，全量升级后收紧为丢弃并上报。
- IM 回调进入核心域统一处理，沉淀审计与风控扩展点。
2.4 直播商品
解决问题： 直播间卖货的核心能力——选品、排序、讲解、多渠道隔离。
- 职责边界： 直播间与商品的关系维护、序号排序、上车（可加购）控制、弹品推送、分类、搜索限定；商品本身的数据与价格归商品中心。
- 核心数据模型：
- 直播-商品关系表：直播间 ID、商品 ID、全局序号、排序值、上车状态、推送状态、渠道快照、创建 / 更新时间。
- 特殊分类关系表：直播间 ID、商品 ID、分类类型（如推荐位）。
- 关键接口：
- 管理端：批量添加、删除、排序、上车 / 下车、弹品 / 取消弹品、按渠道筛选列表。
- C 端：商品分页、全量 ID 列表、分类列表、分类商品 ID、搜索。
- 核心流程（添加商品）：
- 锁定直播间行（串行化同直播间并发添加）。
- 批量查询商品中心，校验：商品存在、非草稿 / 非回收、非限制品类、商品渠道与直播间租户平台匹配。
- 校验请求内与库内均无重复（唯一索引兜底）。
- 按输入顺序生成全局递增序号与排序值，写入渠道快照。
- 核心流程（C 端查询）： 按
直播间 + 渠道 + 上车状态在数据库分页前过滤，再取本页商品去商品中心批量查详情与价格。 - 上下游依赖： 商品中心（详情 / 价格 / 库存 / 搜索）、互动消息（弹品广播）。
- 技术要点：
(直播间, 商品)唯一索引防重，不依赖"先查后写"。- 查询组合索引：
liveId + channel + cartStatus + sort，覆盖排序场景。 - 序号是直播间全局维度：渠道过滤后序号允许不连续，禁止 C 端按下标重编。
- 搜索链路：先取当前渠道上车商品 ID 集合 → 商品中心按
ID 集合 + 渠道 + 关键词搜索并完成分页，避免"先分页再求交集"导致总数错误。 - 历史数据回填使用主键游标批量任务，支持 dry-run、可重入，回填完成后再收紧字段非空约束。
2.5 交易联动
解决问题： 直播场景从"看"到"买"的闭环，以及流量归因。
- 职责边界： 加购校验、下单归因、商品快照；订单与履约主流程归交易域。
- 关键能力：
- 加购校验： 购物车校验商品渠道与用户当前请求渠道一致，不一致拒绝加购，作为跨渠道商品的最后一道防线（服务端列表已过滤，此处兜底）。
- 直播归因： 直播间发起的订单携带直播间 ID，用于后续转化分析与结算；提供归因修复任务处理链路异常数据。
- 商品快照： 下单时冻结商品信息快照，商品后续改价改图不影响历史订单展示。
- 上下游依赖： 购物车、交易校验、订单、商品快照中心、商品中心。
2.6 营销玩法
解决问题： 直播间的转化促进与用户留存。
- 职责边界： 直播间营销活动的配置、参与、开奖与履约；卡券履约归卡券中心。
- 核心玩法与模型：
- 组团抽奖： 抽奖轮次表（直播间、状态、成团人数、奖品、兑换类型、起止时间、渠道券配置 JSON）、组团表（发起人、轮次、组团状态）、成员表（用户、中奖状态、兑奖信息）。
- 兑换类型： 填写收货地址、普通卡券（自动发放）、渠道卡券（用户先选发放渠道，异步 Job 发券）。
- 直播优惠券： 直播间维度发券，走卡券中心。
- 开播提醒： 直播间预约，到点经消息推送平台按场景批量触达。
- 核心流程（渠道卡券）： 中奖 → 用户在有效期内选择渠道（二次确认、不可改选）→ 保存选择与券快照 → 定时任务扫描已选未发记录发券 → 状态回写。
- 技术要点：
- 幂等：同渠道重复提交返回成功；已选后改选拒绝；超时重试以查询结果恢复状态。
- 发券 Job 可重入，按状态机推进，失败记录可人工重跑。
- 轮次配置需校验渠道合法性（轮次渠道必须在租户渠道目录内）。
2.7 多租户与多渠道
解决问题： 一套系统支撑多个租户（独立品牌 / 独立 App），租户内再细分业务渠道（不同国家 / 地区），商品、缓存、消息互不串数据。
- 核心模型：
- 租户 / 平台映射： 每个直播间归属一个平台值，平台值映射租户；直播间类型与平台联动。
- 渠道能力目录： 集中定义"租户 → 渠道列表 → 渠道可用场景"（如：资源位路由、直播商品、抽奖渠道券），各端校验统一取自目录，避免散落硬编码。
- 渠道解析与校验（C 端）：
- 前端全局请求拦截器统一注入业务渠道请求头，页面不自行拼装。
- BFF 入口解析渠道并校验与直播间平台匹配：
- 渠道缺失 / 不匹配 → 返回明确业务错误（fail-closed），禁止静默回落默认渠道掩盖缺陷；
- 存量单渠道租户可配置兼容回落，用于发布过渡。
- 渠道校验通过后作为显式参数向下游传递，全程不再读请求上下文。
- 数据与缓存隔离：
- 渠道以快照形式落直播-商品关系表，查询以快照为准，不逐次回查商品中心。
- 所有缓存 Key 必须包含渠道（列表、分类、搜索、讲解、地址）。
- IM 讲解消息携带渠道，客户端按匹配规则展示或清空。
- 前端本地缓存与请求按
直播间 + 渠道隔离，切渠道时清空未完成请求与页面状态。
- 发布策略（三段式开关）： 详见第 3 章 M6。
2.8 C 端聚合层
解决问题： C 端一次请求聚合多域数据，兼顾性能与一致性。
- 职责边界： 接口编排、渠道解析、数据组装、缓存；不承载业务规则（规则在核心域）。
- 关键接口： 直播详情（房间 + 资源位 + 讲解商品）、商品分页 / 分类 / 搜索、玩法查询与提交。
- 接口编排要点：
- 异步并发： 在请求线程一次性构建不可变查询上下文（用户会员等级、默认地址、白名单、渠道），再提交并发任务查询商品详情、价格、库存；工作线程只消费上下文，禁止读取 ThreadLocal，避免线程池串数据。
- 资源位选路： 支持统一链接与按渠道链接两种路由模式；按渠道模式下未配置当前渠道时返回空（fail-closed），后端选好最终链接，前端不做渠道判断。
- 缓存设计：
- 多级缓存（本地 + 分布式），注解 Key 在方法参数层显式含渠道，禁止方法体内解析导致 Key 缺渠道。
- 降级：下游异常时列表 / 分类返回空结果并记录错误日志，不回退查询其他渠道缓存。
2.9 管理后台
解决问题： 运营人员低门槛、防错地配置直播业务。
- 职责边界： 直播间、直播商品、资源位、营销玩法的配置界面与操作约束；权限归统一认证平台。
- 关键能力：
- 直播间表单：类型与平台联动、推流地址与流状态预览（内嵌播放器）。
- 直播商品：渠道筛选与彩色标签、异常渠道标记并禁止推送、仅"全部渠道"视图下开放拖拽排序并提示"排序值为全局序号"。
- 资源位：统一 / 按渠道路由配置，渠道缺失时前端明示。
- 抽奖轮次：渠道券配置需校验租户渠道目录。
- 技术要点： 所有写操作经管理端聚合服务转发核心域，复用同一套校验；关键操作记录审计日志。
2.10 数据与统计
解决问题： 直播间经营效果可量化。
- 关键能力： 观看 UV 统计（进入上报 + 去重任务）、直播间数据辅助任务（如峰值在线）、回放播放数据、测试数据清理。
- 建议补强： 观看 → 加购 → 下单转化漏斗、渠道维度拆分指标、直播间大促实时看板（详见第 7 章）。
3. 从 0 到 1 建设路径
| 里程碑 | 交付内容 | 数据变更 | 发布顺序与灰度 | 回滚方案 |
|---|---|---|---|---|
| M1 基础直播间 | 核心域服务骨架、直播间管理、推拉流、录制回放、管理后台直播间表单 | 直播间主表、录制表 | 先核心域，后管理端；单服务无依赖可独立回滚 | 服务回滚即可，表结构向前兼容 |
| M2 实时互动 | IM 群组、弹幕公告、讲解商品推送、消息回调 | 无独立表（群属性在云侧） | 群组创建随直播间创建灰度；旧直播间无群时 C 端降级不展示互动区 | 关闭消息广播开关，C 端回到纯观看模式 |
| M3 直播商品 | 关系表、添加 / 排序 / 弹品、分类搜索、商品中心对接 | 直播-商品关系表、特殊分类关系表及索引 | 先管理端写入，后 C 端查询；C 端接口带开关，异常时回源降级 | 读开关关闭后 C 端回退商品中心直查或空态 |
| M4 交易闭环 | 加购渠道校验、下单直播归因、商品快照接入 | 订单扩展归因字段 | 校验逻辑先埋点观察后阻断；归因字段可空向后兼容 | 校验降级为只记录不拦截 |
| M5 营销玩法 | 组团抽奖全流程、渠道卡券、直播券、开播提醒 | 抽奖轮次 / 组团 / 成员三表 | 单直播间灰度开玩法；发券 Job 先 dry-run 再正式 | 关闭玩法入口；未发券记录人工核对后补偿 |
| M6 多渠道 | 渠道能力目录、渠道解析校验、渠道快照、全链路隔离 | 关系表增加渠道字段（先可空）+ 组合索引 + 唯一索引 | 三段式： ① 写开关开启（新数据带渠道，读旧行为）② 渠道回填任务（dry-run → 正式 → 校验空渠道为 0 → 字段收紧 NOT NULL）③ 读过滤开关开启 → 严格校验开启 | 回滚顺序：关严格校验 → 关读过滤 → 回滚上层；渠道字段与已回填数据默认保留；如必须回滚写服务，先把字段改回可空再发旧版，禁止给字段设默认渠道值 |
| M7 数据统计 | UV 统计、统计任务、看板 | 统计结果表 | 只读能力，随任务上线 | 任务下线即回滚 |
里程碑依赖关系： M1 → M2 → M3 → M4 串行为主线；M5 依赖 M3/M4；M6 依赖 M3 稳定（渠道化是对存量能力的改造，需三段式灰度）；M7 可与 M4 后并行。
4. 数据模型设计
| 表 | 核心字段 | 约束 / 索引 | 设计要点 |
|---|---|---|---|
| 直播间主表 | id、主题、封面、开播 / 关播时间、平台、类型、IM 群 ID、流名称、状态、扩展 JSON | pk_id；idx_平台+状态+开播时间（列表查询） | 扩展 JSON 承载租户差异；类型与平台联动由应用层校验 |
| 直播录制记录表 | 直播间 ID、流名称、录制任务 ID、视频列表 JSON | pk_id；idx_直播间 | 视频列表存 JSON，适配云侧一次任务多产物 |
| 直播-商品关系表 | 直播间 ID、商品 ID、渠道、全局序号、排序值、上车状态、推送状态 | uk(直播间, 商品)；idx(直播间, 渠道, 上车状态, 排序值)；idx(直播间, 渠道, 上车状态, 序号) | 渠道为添加时快照，最终 NOT NULL 且不设默认值；唯一索引不含渠道——同一商品不允许以两个渠道重复入库，渠道冲突应作为数据错误暴露 |
| 特殊分类关系表 | 直播间 ID、商品 ID、分类类型 | uk(直播间, 商品, 分类类型) | C 端分类查询建议与关系表单库 Join，避免两集合内存求交 |
| 抽奖轮次表 | 直播间 ID、状态、成团人数、奖品 JSON、兑换类型、起止时间、渠道券配置 JSON | pk_id；idx_直播间+状态 | 渠道券配置存 JSON，读取时校验渠道目录 |
| 组团表 / 成员表 | 轮次 ID、发起人 / 用户、组团状态、中奖状态、所选渠道、发券状态 | uk(轮次, 用户)；发券状态推进含时间戳 | 成员表记录渠道选择与券快照，支撑幂等与审计 |
| 统计结果表 | 直播间 ID、日期、UV、峰值在线等 | uk(直播间, 日期) | 明细上报与结果表分离，任务期聚合 |
通用规范： 表名小写下划线、单数；是 / 否字段 is_xxx 取值 1/0；索引命名 pk_ / uk_ / idx_ 前缀；新表默认含主键与创建 / 更新时间；金额用 DECIMAL。
5. 关键设计决策
| # | 决策 | 备选方案 | 采用理由与取舍 |
|---|---|---|---|
| 1 | 渠道快照落关系表，查询以快照为准 | 每次查询实时回查商品中心 | 分页前可过滤、性能可控、不依赖外部服务可用性；代价是商品渠道变更后需删除重加修复（首期接受，配告警） |
| 2 | 商品序号为直播间全局序号，渠道过滤后不重编 | 各渠道独立编号 | 运营配品排序心智一致，跨渠道对账简单；代价是 C 端序号不连续，需前端约定不重编 |
| 3 | 数据库分页前过滤渠道 | 先分页再后置过滤 | 后置过滤会导致空页与总数错误，是典型线上缺陷模式 |
| 4 | 渠道缺失 / 不匹配 fail-closed，返回明确业务错误 | 静默回落默认渠道 | 回落会掩盖客户端缺陷并造成跨渠道串数据；发布期才允许配置兼容回落 |
| 5 | 唯一索引防重，而非"先查后写" | 应用层查重 | 并发添加下查重有竞态；唯一索引是最终防线，冲突转为可识别错误 |
| 6 | 同直播间写操作行锁串行化 | 分布式锁 | 加品 / 排序强关联单行记录，行锁最简单可靠，且避免引入额外组件；锁内不做远程调用 |
| 7 | 异步任务显式传上下文，工作线程不读 ThreadLocal | 工作线程透传请求上下文 | 线程池复用线程易串用户数据；不可变上下文可测试、可缓存 |
| 8 | 缓存 Key 强制含渠道，降级不跨渠道回退 | 降级时查默认渠道 | 跨渠道回退 = 数据事故；宁可空结果也不串渠道 |
| 9 | 三段式开关发布渠道化（写 → 回填收紧 → 读 → 严格） | 一次性切换 | 存量数据与旧客户端无法同步升级；开关组合有明确矩阵，禁止越阶 |
| 10 | 购物车作为渠道校验最终防线 | 仅依赖列表过滤 | 防御纵深：即使上游漏过滤，加购仍被拦截 |
| 11 | 讲解商品走 IM 群属性 + 自定义消息双通道 | 仅自定义消息 | 群属性保证新进观众秒见当前商品，消息保证实时变更 |
| 12 | 发券异步 Job 化 + 状态机幂等 | 同步发券 | 中奖瞬时高峰削峰；幂等与可重跑保证最终一致 |
6. 非功能设计
缓存策略
- 多级缓存（进程内 + 集中式），直播商品列表 / 分类 / 搜索 / 讲解 / 用户默认地址全部纳入。
- Key 规范：
业务域:对象:{直播间}:{渠道}:{维度}:{分页}，注解缓存的 Key 必须在方法参数中取得渠道。 - 失效：商品增删 / 排序 / 上下车后主动失效对应直播间与渠道的全部相关 Key。
- 降级：缓存查询异常回源数据库并限流；下游服务异常返回空态 + 错误日志，不做跨渠道兜底。
幂等与并发
- 写接口以业务唯一键幂等（如抽奖选择渠道：同渠道重复提交成功）。
- 定时任务统一支持 dry-run、游标分批、可重入（更新条件带状态前置校验）。
- 同直播间写操作数据库行锁串行化；跨服务操作按"锁内不做 RPC"原则拆分事务。
监控与告警
| 指标 | 告警条件 |
|---|---|
| 渠道请求量（按直播间 / 渠道维度） | 突降可能代表端上未带渠道头 |
| 渠道缺失 / 不匹配错误量 | 持续增长说明端上发布未收口 |
| 关系表空渠道记录数 | 大于 0 即告警（回填遗漏） |
| 关系渠道与商品中心渠道不一致数 | 大于 0 即告警（需运营修复） |
| 搜索结果空但总数大于 0 | 过滤逻辑缺陷信号 |
| 讲解推送量（按渠道） | 与运营排期偏离时人工核查 |
日志规范：关键链路日志必含直播间 ID、商品 ID、渠道、平台、链路追踪 ID；渠道信息脱敏按平台规范执行。
容量与降级
- 大促前对"商品列表聚合链路"压测（关系查询 + 商品中心批量详情 + 价格），评估缓存命中率与并发任务线程池上限。
- 直播详情页各数据块独立降级：讲解商品、资源位、玩法任一异常不影响直播间主画面。
- IM 依赖不可用时，C 端退化为轮询讲解商品群属性快照或静态兜底，直播主流程不受阻。